\chapter{Outlook and Summary}
\section{Outlook}
The presented algorithm and its implementation have potential for improvement.
Our initial concept for boundary value analysis can be extended and become a full grown support for data based coverage criteria. Therefore we need to implement an algorithm that automatically generates objective functions from the model. Depending on the desired data based coverage criterion for each path a suitable set of objective functions can be generated and used to find all test data fulfilling the data--based coverage criterion.\\
In order to make an industrial--strength tool out of this prototypical implementation, one should improve the scalability of the \nameref{sec:pathsearch} step. Currently we support an infeasible model structure--based coverage criterion. %in a way that it does not generate one test case for every feasible path but only as many test cases as necessary to fulfil a feasible coverage criterion. This would massively improve the scalability of our algorithm for larger models. The combinatorial explosion of possible control flow paths currently causes the overall runtime of our algorithm to grow exponentially. 
When the total number of test cases to generate depends linearly on the number of edges or nodes in the activity test case graph, the overall runtime of our algorithm will be reduced to depend polynomially on the number of nodes or edges in the activity test case graph. For example one can ensure that for each edge there is at least one test case traversing this edge. Or one can use the test goal management implemented in ParTeG. This allows selecting multiple coverage criteria that shall be fulfilled by the generated test suite and steers the test case generation accordingly \cite{weissleder2010parteg}.\\
Another potential is buried in the mathematical modelling system. The modelling capabilities of AMPL are currently not used to their full extent. AMPL natively supports arrays with a fixed length. Our current algorithm interprets every \UMLType{Property} or \UMLType{Parameter} with a basic data type as a single variable. We could also interpret the multiplicity of \UMLType{Parameters} or \UMLType{Properties} and interpret them as arrays of fixed lengths. This could be done with almost no implementation effort.\\
Besides arrays AMPL also natively supports more mathematical operations than those that are predefined in basic OCL and via an external library support for a huge selection of scientific arithmetic functions is available. By extending the OCL parser, functions like \texttt{sin}, \texttt{exp}, and different probability distributions can easily be made available to the formulation of constraints.\\
Another improvement which is also provisioned is the handling of object type variables. This would need some modifications in the way how activity test case graphs are transformed into AMPL models and also requires an extension of the OCL subset that is accepted as input language for constraints.\\
Finally, the transformation from UML into an activity test case graph could be extended such that more modelling elements from the UML are supported. Support for \UMLType{ActivityCallActions} or \UMLType{LoopNodes} can be added by inlining the referenced activity of an \UMLType{ActivityCallAction} or the body of a \UMLType{StructuredActivityNode}. We can also support arbitrary \UMLType{DataTypes} by allowing a user--defined mapping of data types to one of the basic data types: boolean, integer, or real. For example, the user could use the \UMLType{DataTypes} named `uint8', `uint16', and `uint32'; one can define in the model that they are integers with a specified value range.
%and a huge variety of scientific arithmetic functions 
%Tell about Implementation of Object and Compound Variables and handling of arrays.
%Suppose alternative Mathematical Modelling Systems. GAMS, SMT-LIB, GLPK.
\section{Summary}
We presented an approach for automated generation of unit test from UML activity and class models. The presented approach consists of five steps transforming an UML activity diagram into a unit test through four intermediate artefacts. We also specified at least one algorithm for each step and demonstrated the practicality of our approach by implementing it as Eclipse plug-in and applying it to a set of academic test models and a model of a real industrial software implementation from Airbus. With mutation testing we demonstrated that the presented approach is useful and fully working. We examined in detail the influence of different parameters of our algorithm on the total runtime and performed a parameter tweaking.\\
% The presented architecture has provisions for further development and improvement of our initial proof--of--concept implementation. The defined interfaces between the transformation steps serve as framework where the intermediate steps can be developed independently from each other and helps to keep complexity of the sub algorithm low. The Framework also allows for easy adoption of our approach to another input language, or another output language, or make some advanced selection of test cases to fulfil a user specified coverage criterion.\\
We presented an efficient way to integrate state--of--the--art constraint solvers and provide support for a wide variety of mathematical problems. Depending on the specific needs of the modeller we can allow a wide variety of constraint expressions to be used in the test model. All constraint solvers are accessed via a common interface, thus, making it easy to exchange the constraint solver and selecting the one that is most suitable to generate test data for one specific activity diagram. We presented several example models, each holding constraints that are instances of a different mathematical problem. We argued which solver is suitable for which model and also measured the runtime of the implementation. We clearly saw that the automatic test data generation is especially fast when constraints are specified in terms of a decidable theory with a tractable algorithm, for example, linear programming. On the other hand we also successfully demonstrated test data generation for models whose constraints are formulated as instances of an undecidable problem, for example, mixed integer non--linear programming. Although it is in general possible with our approach to generate test data for models with undecidable constraints it can be much more time consuming than generating test data for models with decidable constraints and it is not guaranteed that an existing solution will be found. We recommend restricting oneself to linear inequalities or another decidable constraint formulation, if that is possible. One should use mixed integer non--linear constraints or SMT formulas with an undecidable theory only for small models and if it is unavoidable.\\
We have presented a concept for early infeasible path elimination during generation of abstract test cases and examined its impact on the overall runtime of our algorithm. We have also examined the influence of several parameters on the runtime of our implementation. Using early infeasible path elimination with two unchecked steps massively reduces the runtime of our algorithm especially for larger models when one test case is generated for every feasible path with a maximum path length of 60 control flows or more. Of course, those results strongly depend on the activity diagrams used for this examination, but we assume that our case study model is a good representative of actual models occurring in practice.\\
Finally, we argued that with the presented approach it is possible to steer the generation of test data in a way that boundary values are produced with no additional effort. It is common knowledge that the use of boundary values as test data tends to trigger existing bugs with a higher probability. Thus we improved the quality of the generated test cases with a minimal additional effort.
%I build a rudimentary tool which can fully automatically generate boost test code for C and CPP from UML Activities. Up to now it only provides support for Arithmetic and Logical Constraints. Object and Set types can not be supported due to time running out. The chosen approach with a mathematical programming language makes it out of the box suitable for a large variety of Constraints and also extremely large Models when only quadratic Mixed Integer Programming is needed.
